Add unit tests for sorting algorithms and configure CI pipeline#32
Conversation
There was a problem hiding this comment.
Pull request overview
Adds automated testing and CI coverage for the sorting visualizer by introducing JUnit-based correctness tests, wiring Maven to execute them, and running mvn verify in GitHub Actions.
Changes:
- Added a JUnit 5 test suite to validate that each sorting algorithm produces a sorted
ArrayController. - Updated
pom.xmlto include JUnit Jupiter and configure the Maven test runner. - Added a GitHub Actions CI workflow to build and run tests on PRs/pushes to
main.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
src/test/java/io/github/compilerstuck/SortingAlgorithms/SortingAlgorithmsTest.java |
New parameterized tests that run each algorithm against multiple input scenarios (plus a separate BogoSort test). |
pom.xml |
Adds JUnit 5 dependency and configures Surefire to discover and run *Test.java. |
.github/workflows/ci.yml |
New CI workflow to run mvn clean verify on JDK 25. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| // we'll test three common scenarios: random data, already-sorted, and reverse-sorted | ||
| int[][] datasets = new int[4][]; | ||
| datasets[0] = randomPermutation(size, 12345L + size); | ||
| datasets[1] = new int[size]; | ||
| datasets[2] = new int[size]; | ||
| datasets[3] = new int[size]; |
There was a problem hiding this comment.
The comment says the test covers “three common scenarios”, but the code builds 4 datasets (random, sorted, reverse, duplicates). Update the comment or the datasets so they match; otherwise it’s easy to misread what’s actually being tested.
| for (int i = 0; i < size; i++) { | ||
| datasets[1][i] = i; // already sorted | ||
| datasets[2][i] = size - i - 1; // reverse order | ||
| datasets[3][i] = i % 5; // many duplicates | ||
| } |
There was a problem hiding this comment.
The “duplicates” dataset introduces repeated values (i % 5). The production ArrayController always creates/shuffles permutations of 0..n-1 (unique values), and at least some algorithms here assume that invariant (e.g., CycleSort can increment pos past the end when skipping duplicates). This test case is likely to fail or be out-of-scope for the visualizer’s data model; consider removing it or restricting it to algorithms explicitly intended to handle duplicates.
| @BeforeAll | ||
| static void setupMainController() { | ||
| // set static processing field so that algorithms don't hit NPE if they | ||
| // accidentally call it even though we disable delays in the tests. | ||
| MainController.processing = new DummyProcessing(); | ||
| } |
There was a problem hiding this comment.
This test mutates global static state (MainController.processing) but never restores it. To avoid test-order coupling as the suite grows, store the previous value and restore it in an @AfterAll (or set/reset per-test).
| @Test | ||
| @DisplayName("BogoSort eventually produces a sorted array (small size)") | ||
| @org.junit.jupiter.api.Timeout(value = 5) | ||
| void bogoSortSmallArray() { | ||
| int size = 4; // small enough that random swaps finish in a reasonable time | ||
| ArrayController controller = new ArrayController(size); | ||
| int[] values = randomPermutation(size, 42L); | ||
| for (int i = 0; i < size; i++) { | ||
| controller.set(i, values[i]); | ||
| } | ||
|
|
||
| BogoSort algo = new BogoSort(controller); | ||
| algo.setDelay(false); | ||
| // run for a capped number of iterations to avoid infinite loops in case | ||
| // something is wrong; the implementation keeps trying until sorted, so we | ||
| // simply execute the method on the small array. | ||
| algo.sort(); | ||
| assertTrue(controller.isSorted(), "BogoSort did not sort the small array"); |
There was a problem hiding this comment.
BogoSort.sort() uses a non-seeded new Random() loop-until-sorted. Even with a small array and a timeout, this makes the test non-deterministic and potentially flaky on slower/loaded CI. Prefer making the randomness deterministic for the test (e.g., allow injecting a seeded Random) or add a bounded-tries mode that the test can assert on.
Add automated tests and CI support for sorting algorithms.
DummyProcessingstub to satisfyMainControllerin tests.pom.xmlwith JUnit dependency and Surefire plugin..github/workflows/ci.yml) to build & run tests on every push/PR.